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The Network Trouble Ticket Data Model (NTTDM) 
Abstract 
Handling multiple sets of network trouble tickets (TTs) originating 


from different participants’ inter-connected network environments 
poses a series of challenges for the involved institutions. A Grid 


is a good example of such a multi-domain project. Each of the 
participants follows different procedures for handling trouble in its 
domain, according to the local technical and linguistic profile. The 


TT systems of the participants collect, represent, and disseminate TT 
information in different formats. 


As a result, management of the daily workload by a central Network 
Operation Centre (NOC) is a challenge on its own. Normalization of 
TTs to a common format at the central NOC can ease presentation, 
storing, and handling of the TTs. In the present document, we 
provide a model for automating the collection and normalization of 
the TT received by multiple networks forming the Grid. Each of the 
participants is using its home TT system within its domain for 
handling trouble incidents, whereas the central NOC is gathering the 
tickets in the normalized format for repository and handling. XML is 
used as the common representation language. The model was defined 
and used as part of the networking support activity of the EGEE 
(Enabling Grids for E-sciencE) project. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for examination, experimental implementation, and 
evaluation. 


This document defines an Experimental Protocol for the Internet 
community. This is a contribution to the RFC Series, independently 
of any other RFC stream. The RFC Editor has chosen to publish this 
document at its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 
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Introduction 


Problem-impact assessment, reporting, identification, and handling, 
as well as dissemination of trouble information and delegation of 
authority, are some of the main tasks that have to be implemented by 
the members of a Grid in order to successfully manage the network and 
maintain operational efficiency of the services offered to their 
users. 


Different TT systems are used by each network domain, delivering TTs 
in alternate formats, while the TT load is growing proportionally 
with network size and serviced users. 


We hereby define a data model for TT normalization -- the Network 
Trouble Ticket Data Model (NTTDM) -- initially targeted for network 
providers serving EGEE [8]. The model is designed in accordance with 


RFC 1297 [11] and meets requirements of the multiple TT systems used. 
The NTTDM 


o is both effective and comprehensive, as it compensates for the 
core activities of the Network Operation Centres (NOCs). It is 
also dynamic, allowing additional options to be included in the 
future, according to demand. 


o provides an XML representation for conveying incident information 
across administrative domains between parties that have an 
operational responsibility of remediation or a "watch-and-warn" 
policy over a defined constituency. 


o encodes information about hosts, networks, and the services 
running on these systems; attack methodology and associated 
forensic evidence; impact of the activity; and limited approaches 
for documenting workflow. 


o aims to simplify TT exchange within the boundaries of a Grid and 
to enhance the functional cooperation of every NOC and of the Grid 
Operation Centre (GOC). Community adoption of the NTTDM enhances 
trouble resolution within the Grid framework and imparts network 
status cognizance by modeling collaboration and information 
exchange among operators. 
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O provides a common format that allows GOCs as well as all 
participating NOCs to store, exchange, manage, and analyze TTs 
(assessment of TT impact). 


o provides increased automation in handling a TT, since the network 
operators have a common view of the incident. 


The model was designed and used as part of the networking support 
activity of the EGEE project; one of the subtasks of this support 
activity was to enhance the ENOC (EGEE Network Operation Centre) [9] 
procedures for better overall network coordination of the Grid. 


1.1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in REC 2119 [1]. 


The NTTDM uses specific keywords to describe the various data 
components. These keywords are: 


Defined, Free, Multiple, List, Predefined String, String, 
Datetime, Solved, Cancelled, Inactive, Superseded, Opened/Closed, 
Operational, Informational, Administrative, and Test. 


These keywords as used in this document are to be interpreted as 
described in Section 2. 


Acronyms: 
TT: Trouble Ticket 
NTTDM: Network Trouble Ticket Data Model 
DB: Database 
EGEE: Enabling Grid for E-sciencE 
ENOC:  EGEE NOC 
NOC: Network Operation Centre 
GOC: Grid Operation Centre 
NREN: National Research and Educational Network 


QoS: Quality of Service 
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UML: Unified Modeling Language 
XML: Extensible Markup Language 
1.2. Notations 
The NTTDM is specified in two ways: as an abstract data model and as 
an XML Schema. Section 3 provides a Unified Modeling Language (UML) 


[10] model describing the individual classes and their relationship 
with each other. The semantics of each class are discussed and their 


attributes explained. In Section 6, this UML model is converted into 
an XML Schema [2] [3] [4] [5]. A specific namespace [6] is also 
defined. 


The term "XML document" refers to any instance of an XML Document. 
The term "NTTDM document" refers to specific elements and attributes 
of the NTTDM Schema. Finally, the terms "class" and "element" are 
used interchangeably to reference either a given UML class in the 
data model or its corresponding Schema implementation. 


1.3. About the Network Trouble Ticket Data Model 


The NTTDM is a data representation that provides a framework for 
normalizing and sharing information among network operators and the 
GOC regarding troubles within the Grid boundaries. There has been a 
lot of thought processing during the design of the data model: 


o The data model serves as a common storage and exchange format. 


o Every NOC still uses its home TT system for network management 
within its area of control. 


o As there is no universally adopted definition for a trouble, in 
the NTTDM definition, the term is used with a comprehensive 
meaning to cover all NOCs. 


o Handling every possible definition of a trouble incident would 
call for an extremely expanded and complex data model. Therefore, 
the NITDM’s purpose is to serve as the basis for normalizing and 
exchanging TTs. It is flexible and expressive in order to ensure 
that specific NOC requirements are met. Specific NOC information 
is kept outside the NITDM, and external databases can be used to 
feed it. 
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o The domain of managing the information is not fully standardized 
and must rely on free-form textual descriptions. The NTTDM 
attempts to strike a balance between supporting this free-form 
content, while still allowing automated processing of incident 
information. 


The NTTDM is only one of several feasible TT data representations. 
The goal of this design was to be as effective and comprehensive as 
these other representations and to account for the management of a 
general Grid environment. The already used TT formats influenced the 
design of the NTTDM. 


1.4. About the Network Trouble Ticket Implementation 


Here we describe an example of a typical use case. 


The Grid project EGEE manages its infrastructure as a network overlay 
over the European National Research and Educational Networks (NRENs) 
and wants to be able to warn EGEE sites of the unavailability of the 
network. Thanks to collaboration with its network provider, the EGEE 
NOC receives a high volume of TTs (800 tickets/month, 2500 
emails/month) from 20 NRENs and should always be able to cope with 
such a heavy load. Thanks to the NTTDM, the EGEE NOC can automate 
the TT workflow: 


o The TT is filtered, sorted, and stored in a local database (DB). 
o The TT's impact on the Grid is assessed. 


o The TT is pushed to an ENOC dashboard application and other tools 
(EGEE TT system, statistics, etc.). 


1.5. Future Plans 


Since this is an Experimental document, operational experience will 
be used to expand the subsections of Section 3.2.3, "Ticket Origin 
Information", below. The current specification is already used 
within EGEE. Other Grids are free to use it and report comments to 
the authors. After enough experimentation, we would like to advance 
it to the Standards Track. 


2. NTTDM Types and Definitions 


The various data elements of the TT data model are typed. This 
section discusses these data types. When possible, native Schema 
data types were adopted, but for more complicated formats, regular 
expressions or external standards were used. 
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2.1. Types and Definitions for the TYPE Attribute 
These types are used to describe the TYPE attribute. 
2.1.1. Defined 


The Defined data type means that the data model provides a means to 
compute this value from the rest of the fields. 


The Defined data type is implemented as "Defined" in the Schema. 
2.1.2. Free 

The Free data type means that the value can be freely chosen. 

All Free strings SHOULD have as an attribute the language used. 

The Free data type is implemented as "Free" in the Schema. 
2.1.3. Multiple 


The Multiple data type consists of one value among multiple fixed 
values. 


The Multiple data type is implemented as "Multiple" in the Schema. 
2.1.45 CELSE 


"List" means many values among multiple fixed values. The List data 
type is implemented as "List" in the Schema. 
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2.2. Types and Definitions for the VALID FORMAT Attributes 
2.2.1. Predefined String 


A Predefined String means the different values are predefined in the 
data model. 


Each field that requires a Predefined String contains a specific 
value. Figure 1 shows the allowed values for such fields. 


4------------------------ $ + 
| FIELD NAME | VALUES | 
4------------------------ $ + 
| TT_TYPE | Operational, Informational, 
| | Administrative, Test | 
4------------------------ $ + 
| TYPE | Scheduled, Unscheduled 
4------------------------ $ + 
| TT_PRIORITY | Low, Medium, High 
4------------------------ PO + 
| TT SHORT DESCRIPTION | Core Line Fault, Access Line | 
Fault, Degraded Service, Router 
Hardware Fault, Router Software 
| Fault, Routing Problem, Undefined | 
| Problem, Network Congestion, | 
| Client Upgrade, IPv6, QoS, VoIP, | 
| Other | 
+-+ + 


| 

| 

| 

| 

+ 
TT IMPACT ASSESSMENT | No impact, Reduced redundancy, | 
| Minor performance impact, Severe | 
| performance impact, | 
| No connectivity, On backup, | 
| At risk, Unknown | 
Ho O FO EE EER + 
| TT_STATUS | Opened, Updated, Closed, Solved, | 
| Inactive, Cancelled, Reopened, | 
| Superseded, Opened/Closed | 
FO O + 
| Users, Monitoring, Other NOC | 
4+----------------------------------- + 


+ rana Es 

| TT_SOURCE 

+ —————————— ÁM— NK 
Figure 1. Allowed Predefined String Values 


The Predefined String data type is implemented as "xs:string" in the 
Schema with a sequence of enumerations for the allowed values. 


Zisiadis, et al. Experimental [Page 9] 


RFC 6137 NTTDM February 2011 


2.2.1.1. Definitions of the Predefined Values 
TT TYPE 
o Operational: for network incident and maintenance only. 


o Informational: information about the TT system or the exchange 
interface (maintenance, upgrade). 


o Administrative: information about the access to the TT system 
(credentials) or the exchange interface. 


o Test: to test the TT system or the exchange interface, etc. 
TYPE 

o Scheduled: the incident was scheduled to happen. 

o Unscheduled: the incident was unscheduled. 

TT_PRIORITY 

o Low: the TT priority is low. 

o Medium: the TT priority is medium. 

o High: the TT priority is high. 

TT_SHORT_DESCRIPTION 

o Core Line Fault: malfunction of a high-bandwidth core line. 
o Access Line Fault: malfunction of a medium-bandwidth access line. 
o Degraded Service. 

o Router Hardware Fault: malfunction of the router hardware. 
o Router Software Fault: malfunction of the router software. 
o Routing Problem: incident regarding the routing service. 

o Undefined Problem: nature of the problem not identified. 


o Network Congestion: problem due to traffic at the network 
(blocked). 


o Client Upgrade: incidents regarding client/services upgrade. 
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o IPv6: incident regarding the IPv6 network. 


o QoS: incident regarding the Quality of Service (QoS) of the 
network. 


o VoIP: incident regarding Voice over IP (VoIP). 

o Other: non-listed incident. 

TT IMPACT ASSESSMENT 

o No impact: the incident does not cause any impacts. 


o Reduced redundancy: the incident reduces network redundancy. 


o Minor performance impact: the incident causes a minor performance 
impact. 


o Severe performance impact: the incident causes a severe 
performance impact. 


o No connectivity: the incident causes connectivity failure. 
o On backup: the incident causes a malfunction of backup services. 


o At risk: the incident should not have any impact but could 
possibly cause some trouble. 


o Unknown: the nature of the impact is not identified. 

TT STATUS 

o Opened: the ticket is opened. 

o Closed: the ticket is closed. 

o Updated: the ticket's contents have been updated. 

o Cancelled: the ticket has been opened twice; one of the tickets is 


cancelled, and a relationship between them is defined via the 
RELATED ACTIVITY field. 


o Solved: the incident is solved, but the team prefers to 
monitor/check for future issues. 


o Opened/Closed: the ticket was opened only to report an incident 
that has already been solved. 
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o Inactive: the ticket is under the responsibility of an external 
domain and is no longer under the reporting domain’s control. 


o Reopened: the ticket was closed by error, or the problem was 
erroneously declared to be solved. Data in the History field are 
very important in this case. 


o Superseded: the ticket has been superseded by another one (for 
example, a bigger problem that had resulted in many tickets was 
later merged into a single incident/ticket). The RELATED_ACTIVITY 
field SHOULD include the master ticket reference. 


Allowed transitions for TT_STATUS are only those indicated in 
Figure 2. Possible final states are indicated with (X). 
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4------------------ t 
| Opened/Closed (X)| 
4------------------ + 
| 
| 
V 
4-------------- + 
EE OO OE SES | Reopened | <------------------- y 
| NN L| 
4-------------- + | 
| Å | | 
| | | 
| v | | 
| na T | | 
| | Superseded (x) | | | 
| or Inactive (X) | | 
iO >| or Cancelled (X) |<---\ 
E ——— ZEN | 
| | : | d | 
| | | | v | 
| | +-------- + | +-------- + | 
| | i --------- Opened |----/ Solved |----- ) | 
——————————————— > 
mE — - — + || 
| | d | o | | 
v| v | | i 
18855 + | | | | 
subita zaia AA A vv 
Updated TASAS SSS eer + 
PARRA re | 
+--------- + | | Closed (X) | 
EE scan pan oa >| | 
+------------ + 


Figure 2. TT_STATUS Transition Diagram 
242.29 (String 


The String value is defined by the user of the model. The String 
data type is implemented as "xs:string" in the Schema. 


2.2.3. Datetime 
Date-time strings are represented by the Datetime data type. Each 


date-time string identifies a particular instant in time; ranges are 
not supported. 
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Date-time strings are formatted according to a subset of 
ISO 8601:2000 as documented in RFC 3339. 
The Datetime data type is implemented as "xs:dateTime" in the Schema. 
3. NTTDM 
In this section, the individual components of the NTTDM will be 
discussed in detail. This class provides a standardized 
representation for commonly exchanged Field Name data. 
3.1. NTTDM Components 
3.1.1. NTTDM Attributes 
The Field Name class has four attributes. Each attribute provides 
information about a Field Name instance. The attributes that 
characterize one instance constitute all the information required to 
form the data model. 
DESCRIPTION 
This field contains a short description of the Field Name. 


TYPE 


The TYPE attribute contains information about the type of the 
Field Name it depends on. The values that it may contain are: 


Defined, Free, Multiple, and List. 
VALID FORMAT 


This attribute contains information about the format of each 
field. The values that it may contain are: 


Predefined String, String, and Datetime. 

MANDATORY 
This attribute indicates whether the information of each field is 
required or optional. If the information is required, the 


MANDATORY field contains the word "YES". If the information is 
optional, the MANDATORY field contains the word "NO". 
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3.2. NTTDM Aggregate Classes 
3.2.1. NTTDM-Document Class 


The NTTDM-Document class is the top-level class in the NTTDM. 


All 
NTTDM documents are an instance of this class. 


+--------------- + 

| NTTDM-Document | 

+--------------- + 

| version |<>--{1..*}--[ Ticket ] 
| lang 

+--------------- + 


Figure 3. NTTDM-Document Class 


The aggregate class that constitutes an NTTDM-Document is: 


Ticket 


One or more. The information related to a single ticket. 


The NTTDM-Document class has two attributes: 


version 


STRING. The value of this attribute MUST be "1.00". 


lang 
Required. 


3.2.2. Ticket Class 


Every ticket is represented by an instance of the Ticket class. This 


class provides a standardized representation for commonly exchanged 
TT data. 
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lang 


Required. 


Zisiadis 


r 


et al. 


| 
| <>---------- [ 
| <>---------- [ 
| <>---------- [ 
| <>---------- [ 
| <>---------- [ 
<>--{0..1}--[ 
«»---------- [ 
|<>--{0..1}--[ 
| <>---------- [ 
|«»---------- [ 
|«»---------- [ 
|«»---------- [ 
«»---------- [ 
«»---------- [ 
| <>---------- [ 
|<>--{0..1}--[ 
|<>--{0..1}--[ 
| <>---------- [ 
«»---------- [ 
OR ER LYSE 
|<>--{0..1}--[ 
|<>--{0..1}--[ 
|<>--{0..1}--[ 
|<>--{0..1}--[ 
<>--{0..1}--[ 
<>--{0..1}--[ 
| <>---------- [ 
|<>--{0..1}--[ 
|<>--{0..1}--[ 
| <>---------- [ 
<>--{0..1}--[ 
<>--{0..1}--[ 
|<>--{0..1}--[ 
|<>--{0..1}--[ 
|<>--{0..1}--[ 
|<>--{0..1}--[ 
<>--{0..1}--[ 
<>--{0..1}--[ 
Figure 4. 
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TT: ID 

TT Title 

TT Type 

TT Priority 

TT Status 

TT Source 

TT Open Datetime 

TT Close Datetime 

TT Short Description 
TT Long Description 
Type 

TT Impact Assessment 
Start Datetime 
Detect Datetime 
Report Datetime 

End Datetime 

TT Last Update Time 
Time Window Start 
Time Window End 

Work Plan Start Datetime 
Work Plan End Datetime 
Related External Tickets 
Additional Data 
Related Activity 
History 

Affected Community 
Affected Service 
Location 

Network Node 
Network Link Circuit 
End Line Location A 
End Line Location B 
Open Engineer 
Contact Engineers 
Close Engineer 

Hash 


The Ticket Class 


Experimental 


bh bd bd bd bd bd bd bd bd bd bd bd bd bd bd bd bd bd bd bd bd bd bd bd bd bd A bd bd bd bd bd bd bt bd bt Hy 


February 2011 


[Page 16] 


RFC 6137 NTTDM February 2011 


32. 


The Field Names are the Aggregate Classes that constitute the NTTDM, 


and 


each of them is an element that is characterized by a quadruple 


(DESCRIPTION, TYPE, VALID FORMAT, MANDATORY). 


3: 


Ticket Origin Information 


3.2.3.1. PARTNER ID 


ED GN EE SII a + 
PARTNER_ID | 
So ee See ee EE + 
DESCRIPTION | The unique ID of the TT source partner. 
TYPE | Multiple. 
VALID FORMAT | String. 
MANDATORY | Yes. 
SSS SS SS Se + 


Figure 5. Partner_ID Class 


ORIGINAL_ID 
II INI EIA AI + 
ORIGINAL_ID | 
— ————————— + 
DESCRIPTION | The TT ID that was assigned by the party. 
TYPE | Free. 
VALID FORMAT | String. 
MANDATORY | Yes. 
SS eS ee + 


Figure 6. Original_ID Class 


Ticket Information 


TI TD 
— € M— PE MEN N + 
TESTD | 
—— —— ———— M + 
DESCRIPTION The unique ID of the TT. 
TYPE As defined below. 
VALID FORMAT | String. 
MANDATORY | Yes. 
SS SSS ee SSS os + 


Figure 7. TT ID Class 
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TYPE is constructed as "PARTNER ID" "ORIGINAL ID". PARTNER ID and 
ORIGINAL ID therefore MUST NOT contain an underscore character. 


3.2,4.2. TIL TITLE 


4+--------------- + 
| TT_TITLE | 
4+--------------- + 
DESCRIPTION The title of the TT. 
TYPE Defined. 
| VALID FORMAT | String. 
| MANDATORY | Yes. 
+--------------- + 


Figure 8. TT Title Class 


+--------------- + 
| TT_TYPE | 
+--------------- + 
DESCRIPTION The type of the TT. 
TYPE Multiple. 
| VALID FORMAT | Predefined String. 
| MANDATORY | Yes. 
+--------------- + 


Figure 9. TT Type Class 


4R-------------- + 
| TT_PRIORITY | 

4R-------------- + 

| DESCRIPTION | The TT priority. 

| TYPE | Multiple. 

| VALID FORMAT | Predefined String. 
| MANDATORY | No. 
4R-------------- * 


Figure 10. TT Priority Class 
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32-405. TT STATUS 


4R-------------- * 
| TT STATUS | 

4R-------------- * 

| DESCRIPTION | The TT status. 

| TYPE | Multiple. 

| VALID FORMAT | Predefined String. 
| MANDATORY | Yes. 
4+-------------- + 


Figure 11. TT_Status Class 


+-------------- + 
| TT SOURCE | 
4R-------------- + 
| DESCRIPTION | The source of the ticket. 
| TYPE | Multiple. 
| VALID FORMAT | Predefined String. 
| MANDATORY | No. 
4R-------------- + 
Figure 12. TT Source Class 


3.2.4.7. TT OPEN DATETIME 


4------------------ + 
| TT OPEN DATETIME | 
4------------------ + 
| DESCRIPTION | The date and time when the TT was opened. 
| TYPE | Multiple. 

VALID FORMAT Datetime. 

MANDATORY Yes. 
4+------------------ + 


Figure 13. TT_Open_Datetime Class 
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TT CLOSE DATETIME 


————————————————— + 

TT_CLOSE_DATETIME | 

————————————————— + 

DESCRIPTION | The date and time when the TT was closed. 
TYPE | Multiple. 

VALID FORMAT | Datetime. 

MANDATORY | Yes. 

—————————————————— + 


Figure 14. TT Close Datetime Class 
Trouble Details 


TT SHORT DESCRIPTION 


————————————————————— + 
TT_SHORT_DESCRIPTION | 
————————————————————— + 
DESCRIPTION | The short description of the trouble. 
TYPE Multiple. 
VALID FORMAT Predefined String. 
MANDATORY | Yes. 
————————————————————— T 


Figure 15. TT Short Description Class 


TT LONG DESCRIPTION 


NI A A ILA + 
TT_LONG_DESCRIPTION | 
——— —— P — es a LI T 
DESCRIPTION The detailed description of the 
incident/maintenance reported in the TT. 
TYPE | Free. 
VALID FORMAT | String. 
MANDATORY | No. 
—Ó—————GM—————À ee ee + 


Figure 16. TT_Long_Description Class 
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32-0495. CEYPE 


4R-------------- * 
| TYPE | 

4R-------------- + 

| DESCRIPTION | The type of the trouble. 
| TYPE | Multiple. 

| VALID FORMAT | Predefined String. 

| MANDATORY | Yes. 

4R-------------- * 


Figure 17. Type Class 


3.2.5.4. TT IMPACT ASSESSMENT 


4R---------------------- + 
| TT_IMPACT_ASSESSMENT | 
+---------------------- + 
| DESCRIPTION | The impact of the incident/maintenance. 
| TYPE | Multiple. 
| VALID FORMAT | Predefined String. 
| MANDATORY | Yes. 
+---------------------- + 
Figure 18. TT Impact Assessment Class 
3.2.5.5. START DATETIME 
4---------------- * 
| START DATETIME | 
4R---------------- + 
| DESCRIPTION | The date and time that the 
| | incident/maintenance started. 
TYPE Multiple. 
VALID FORMAT Datetime. 
| MANDATORY | Yes. 
+---------------- + 


Figure 19. Start Datetime Class 
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3.2.5.6. DETECT_DATETIME 


4R------------------- + 
| DETECT_DATETIME | 
4R------------------- + 
| DESCRIPTION | The date and time when the incident 
| | was detected. 
| TYPE | Multiple. 
VALID FORMAT Datetime. 
MANDATORY No. 
4R------------------- + 


Figure 20. Detect_Datetime Class 


3.2.5.7. REPORT DATETIME 


4----------------- + 
| REPORT_DATETIME | 
4+----------------- + 
| DESCRIPTION | The date and time when the incident 
| | was reported. 
TYPE Multiple. 
VALID FORMAT Datetime. 
| MANDATORY | No. 
4+----------------- + 


Figure 21. Report_Datetime Class 


3.2.5.8. END DATETIME 


+-------------- + 
| END_DATETIME | 
+-------------- + 
DESCRIPTION The date and time when the incident/maintenance 
ended. 
| TYPE | Multiple. 
| VALID FORMAT | Datetime. 
| MANDATORY | Yes. 
+-------------- + 


Figure 22. End Datetime Class 
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3.2.5.9. TT LAST UPDATE TIME 


Ho + 
| TT_LAST_UPDATE_TIME | 
+--------------------- + 
| DESCRIPTION | The last date and time when the TT was 
| | updated. 
| TYPE | Multiple. 
VALID FORMAT Datetime. 
MANDATORY Yes. 
4--------------------- + 


Figure 23. TT Last Update Time Class 


3.2.5.10. TIME WINDOW START 


R-—------------------ * 
| TIME WINDOW START | 
R-—----------------- * 
| DESCRIPTION | The window start time in which planned 
| | maintenance may occur. 

TYPE Multiple. 

VALID FORMAT Datetime. 
| MANDATORY | No, unless TYPE is "Scheduled". 
+------------------- + 

Figure 24. Time Window Start Class 


3.2.5.11. TIME WINDOW END 


4R----------------- * 
| TIME WINDOW END | 
4R----------------- * 
DESCRIPTION The window end time in which planned 
maintenance may occur. 
| TYPE | Multiple. 
| VALID FORMAT |  Datetime. 
| MANDATORY | No, unless TYPE is "Scheduled". 
4R----------------- * 


Figure 25. Time Window End Class 
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3.2.5.12. WORK PLAN START DATETIME 


D E E rali + 
| WORK_PLAN_START_DATETIME | 
R-------------------------- + 
| DESCRIPTION | Work planned (expected): start time 
| | in case of maintenance. 
| TYPE | Multiple. 
VALID FORMAT Datetime. 
MANDATORY No. 
++ EER GEE + 


Figure 26. Work Plan Start Datetime Class 


3.2.5.13. WORK PLAN END DATETIME 


4------------------------ + 
| WORK_PLAN_END_DATETIME | 
+------------------------ + 
| DESCRIPTION | Work planned (expected): end time 
| | in case of maintenance. 
TYPE Multiple. 
VALID FORMAT Datetime. 
| MANDATORY | No. 
4------------------------ + 


Figure 27. Work_Plan_End_Datetime Class 


The period delimited by WORK_PLAN_START_DATETIME and 
WORK_PLAN_END_DATETIME MUST be included in the period delimited by 
TIME WINDOW START and TIME WINDOW END, and duplicated with (START, 
END) DATETIME, even in case of maintenance. 


3.2.6. Related Data 


3.2.6.1. RELATED EXTERNAL TICKETS 


4R------------------2-------- + 
| RELATED_EXTERNAL_TICKETS | 

$ + 

| DESCRIPTION | The NOC entity related to the incident. 
| TYPE | ust. 

| VALID FORMAT | String. 

| MANDATORY | No. 

+ + 


Figure 28. Related External Tickets Class 
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3.2.6.2. ADDITIONAL DATA 


4----------------- + 
| ADDITIONAL_DATA | 

4----------------- + 

| DESCRIPTION | Additional information. 
| TYPE | Free. 

| VALID FORMAT | String: 

| MANDATORY | No. 

4----------------- + 


Figure 29. Additional_Data Class 


3.2.6.3. RELATED ACTIVITY 


4+------------------ + 
| RELATED_ACTIVITY | 

4R-----------2------- * 

| DESCRIPTION | The TT IDs of the related incidents. 
| TYPE | Multiple. 

| VALID FORMAT | String. 

| MANDATORY | No. 

4+------------------ + 


Figure 30. Related_Activity Class 


3°23 604. HISTORY 


4£-------------- + 
| HISTORY | 
+---------——-- + 
| DESCRIPTION | The necessary actions/events log. 
| TYPE | Free. 
VALID FORMAT String. 
MANDATORY Yes. 
+---------——- + 


Figure 31. History Class 
Note: This field MUST NOT be empty when the VALID FORMAT attribute 


of the TT_STATUS field is anything other than "OPENED" or 
"OPENED/CLOSED". 
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3.2.7. Localization and Impact 


3.2.7.1. AFFECTED COMMUNITY 


4-------------------- + 
| AFFECTED_COMMUNITY | 
+-------------------- + 
| DESCRIPTION | Information about the community that was 
affected by the incident. 
TYPE Free. 
| VALID FORMAT | String. 
| MANDATORY | No. 
4-------------------- * 


Figure 32. Affected Community Class 


3.2.7.2. | AFFECTED SERVICE 


4------------------ * 
| AFFECTED SERVICE | 
4------------------ + 
DESCRIPTION The service that was affected by the 
incident. 
| TYPE | Multiple. 
| VALID FORMAT | String. 
| MANDATORY | No. 
+------------------ + 


Figure 33. Affected Service Class 


3.2.7.3. LOCATION 


4R-------------- + 
| LOCATION | 
+-------------- + 
| DESCRIPTION | The location (Point of Presence (POP) site, 
| | city, etc.) of the incident/maintenance. 
| TYPE | Multiple. 
| VALID FORMAT | String. 
| MANDATORY | Yes. 
4R-------------- + 
Figure 34. Location Class 
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3.2.7.4. NETWORK NODE 


4R-------------- * 
| NETWORK NODE | 

4R-------------- + 

| DESCRIPTION | The NOC network node related to the incident. 
| TYPE | ' Tist: 

| VALID FORMAT | String. 

| MANDATORY | No. 

4+-------------- + 


Figure 35. Network_Node Class 


3.2.7.5. NETWORK LINK CIRCUIT 


4R-----------2----------- + 
| NETWORK_LINK_CIRCUIT | 
+---------------------- + 
| DESCRIPTION | The name of the network line related 
| | to the incident. 
| TYPE | Dist. 
VALID FORMAT String. 
MANDATORY No. 
+---------------------- + 


Figure 36. Network Link Circuit Class 


3.2.7.6. END LINE LOCATION A 


4R--------------------- + 
| END_LINE_LOCATION_A | 
4R--------------------- + 
| DESCRIPTION | A-end of the link. 
TYPE Multiple. 
VALID FORMAT String. 
| MANDATORY | No. 
+--------------------- + 


Figure 37. End Line Location A Class 
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3.2.7.7. END LINE LOCATION B 


4R--------------------- + 
| END_LINE_LOCATION_B | 
$ ooo + 
| DESCRIPTION | B-end of the link. 
| TYPE | Multiple. 
| VALID FORMAT || String. 
| MANDATORY | No. 
$ ooo + 
Figure 38. End_Line_Location_B Class 
Contact Information 
OPEN_ENGINEER 

+--------------- + 
| OPEN_ENGINEER | 
+--------------- + 
| DESCRIPTION | The engineer that opened the ticket. 

TYPE Multiple. 

VALID FORMAT String. 
| MANDATORY | No. 
+--------------- + 

Figure 39. Open Engineer Class 
CONTACT_ENGINEERS 

4R------------------- + 
| CONTACT_ENGINEERS | 
4R------------------- + 

DESCRIPTION The engineers responsible for the incident 

settlement. 
| TYPE Mr 
| VALID FORMAT | String. 
| MANDATORY | No. 
4R------------------- + 
Figure 40. Contact Engineers Class 
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3.2.8.3. CLOSE ENGINEER 


4+---------------- + 
| CLOSE_ENGINEER | 

4R---------------- + 

| DESCRIPTION | The engineer that closed the ticket. 
| TYPE | Multiple. 

| VALID FORMAT | String. 

| MANDATORY | No. 

4+---------------- + 


Figure 41. Close_Engineer Class 
312.9. Security 


3.2.9.1. HASH 


4------------- + 

| HASH | 

4------------- + 

| DESCRIPTION | Encrypted message hash. 
TYPE Defined. 
VALID FORMAT String. 

| MANDATORY | No. 

4------------- + 


Figure 42. Hash Class 
3.3. NTTDM Representation 
The collected and processed TTs received from multiple 
telecommunications networks are adjusted in a normalized NTTDM. 


Figure 43 shows the representation of this normalized data model. 
The "DESCRIPTION" attribute is implied. 
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4+---------------------- 4+-------- 4R------------------ +--------- + 
| FIELD NAME | TYPE |VALID FORMAT | MANDATORY | 
4+---------------------- 4+-------- 4+------------------ 4+--------- + 
| PARTNER ID | MULTIPLE | STRING | YES 
| ORIGINAL ID | FREE | STRING | YES 
[TT ID [DEFINED |STRING | YES 
[TT TITLE |DEFINED |STRING | YES 
[TT TYPE |MULTIPLE|PREDEFINED STRING |YES 

TT_PRIORITY m PREDEFINED STRING Es 
prec MULTIPLE|PREDEFINED STRING |YES 
| TT SOURCE | MULTIPLE | PREDEFINED STRING |NO 
[TT OPEN DATETIME | MULTIPLE | DATETIME | YES 
| TT_CLOSE_DATETIME | MULTIPLE | DATETIME | YES 
| TT SHORT DESCRIPTION |MULTIPLE|PREDEFINED STRING |YES | 
| TT_LONG_DESCRIPTION | FREE | STRING | NO 
TYPE MULTIPLE|PREDEFINED STRING |YES 
SEO EE STRING ie | 
| START_DATETIME | MULTIPLE | DATETIME | YES 
| DETECT_DATETIME | MULTIPLE | DATETIME | NO 
| REPORT_DATETIME | MULTIPLE | DATETIME | NO 
| END_DATETIME | MULTIPLE | DATETIME | YES 
TT LAST UPDATE TIME T DATETIME he 
i MULTIPLE | DATETIME NO 
| TIME_WINDOW_END | MULTIPLE | DATETIME | NO 
| WORK_PLAN_START_DATETIME | MULTIPLE | DATETIME | NO 
[WORK PLAN END DATETIME |MULTIPLE|DATETIME | NO 
| RELATED EXTERNAL TICKETS |LIST | STRING | NO 
ADDITIONAL DATA FREE STRING NO 
BE hod c Ilo 
| HISTORY | FREE | STRING | YES 
| AFFECTED COMMUNITY | FREE | STRING | NO 
| AFFECTED SERVICE | MULTIPLE | STRING | NO 
| LOCATION [MULTIPLE | STRING | YES 
NETWORK NODE im STRING Bs 
od ced LIST STRING NO 
| END LINE LOCATION A | MULTIPLE | STRING | NO 
| END_LINE_LOCATION_B | MULTIPLE | STRING | NO 
| OPEN_ENGINEER | MULTIPLE | STRING | NO 
| CONTACT_ENGINEERS | LIST | STRING | NO 
CLOSE_ENGINEER MULTIPLE | STRING NO 
HASH DEFINED |STRING NO 
4+------------------------ 4+-------- 4+------------------ 4+--------- + 
43. The Field Name Class 
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4. 


DE 


Du 


Lo 


Internationalization Issues 


Internationalization and localization are of specific concern to the 

NTTDM, since it is only through collaboration, often across language 

barriers, that certain incidents can be resolved. The NTTDM supports 
this goal by depending on XML constructs, and through explicit design 
choices in the data model. 


The main advantage of the model is that it provides a normalized data 
type that is implemented fully in the English language and can be 
used conveniently. It also supports free-formed text that can be 
written in any language. In the future, it will provide translation 
services for all such free-formed text. 


Example 
Link Failure 


In this section, an example of network TTs exchanged using the 
proposed format is provided. This is an actual GRNet ticket 
normalized according to the NTTDM. Fields that were not included in 
the ticket are left blank. 


<?xml version="1.0" encoding-"UTF-8"?» 
<!-- This example describes a link failure that was detected --> 


<NTTDM-Document version="1.00" lang="el" 
xmlns="urn:ietf:params:xml:ns:nttdm-1.0"> 

<Ticket> 

<Original_ID>5985</Original_ID> 

<Partner_ID>01</Partner_ID> 

<TT_ID>01_5985</TT_ID> 

<TT_Title>Forth Link Failure</TT_Title> 

<TT_Type>Operational</TT_Type> 

<TT_Status>Closed</TT_Status> 

<TT Open Datetime>2008-12-16T10:01:15+02:00</TT Open Datetime> 

<TT Short Description>Core Line Fault</TT Short Description> 

<TT Long Description>Forth Link Failure</TT Long Description> 

<Type>Unscheduled</Type> 

<TT Impact Assessment>No connectivity</TT Impact Assessment> 

«Start Datetime>2008-12-16T709:55:00+02:00</Start Datetime> 

«TT Last Update Time>2008-12-16T15:00:34+02:00</TT Last Update Time» 

<Location>HERAKLION</Location> 

<History>Optical transmitter was changed</History> 

<TT_Close_Datetime>2008-12-16T15:05:00+02:00</TT_Close_Datetime> 

<End_Datetime>2008-12-16T15:01:21+02:00</End_Datetime> 
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<Network_Node> 
<Node>FORTH</Node> 
</Network_Node> 
<Network_Link_Circuit> 
<Link_Circuit>FORTH-2</Link_Circuit> 
</Network_Link_Circuit> 
<Open_Engineer>Dimitris Zisiadis</Open_Engineer> 
<Close_Engineer>Guillaume Cessieux</Close_Engineer> 
<Contact_Engineers> 
<Engineer>Spyros Kopsidas</Engineer> 
<Engineer>Chrysostomos Tziouvaras</Engineer> 
</Contact_Engineers> 
<TT_Priority>High</TT_Priority> 
</Ticket> 
</NTTDM-Document> 


6. Sample Implementation: XML Schema 
This section provides a sample XML Schema of the NTTDM. 


<?xml version="1.0" encoding="UTF-8" ?> 
«xs:schema xmlns-"urn:ietf:params:xml:ns:nttdm-0.1" 
xmlns:nttdm-"urn:ietf:params:xml:ns:nttdm-1.0" 
xmlns:xs-"http://www.w3.org/2001/XMLSchema" 
targetNamespace-"urn:ietf:params:xml:ns:nttdm-1.0" 
elementFormDefault-"qualified" 
attributeFormDefault="unqualified"> 
<xs:annotation> 

<xs : documentation 

>Trouble Ticket Data Model v-1.0</xs:documentation> 

</xs:annotation> 


sies 


== NTTDM-Document Class == 


--> 
<xs:element name="NTTDM-Document "> 
<xs:complexType> 
<xs:sequence> 
<xs:element ref="nttdm:Ticket" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:attribute name="version" type="xs:string" fixed="1.00"/> 
<xs:attribute name="lang" type="xs:language" use="required"/> 
</xs:complexType> 
</xs:element> 
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Ticket Class 


<xs:element name="Ticket"> 
<xs:complexType> 
<xs:all> 


«xS 
«xS 
«xS 
«xS 
«xS 
«xS 
«xS 
«xS 
«xs 
«xS 
«xS 
«xS 
«xS 
«xS 
«xS 
«xS 
«xS 
«xS 
«xS 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 

</xs 
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:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:all» 


et al. 


ref="nttdm: 


ref="nttdm 


ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 


ref="nttdm 


ref="nttdm: 


ref="nttdm 


ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
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ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 
ref="nttdm: 


ref="nttdm 


ref="nttdm: 
ref="nttdm: 


Partner_ID"/> 

:Original_ID"/> 

TT_ID"/> 

TT_Title"/> 

TT_Type"/> 

TT_Priority" minOccurs="0"/> 
TT_Status"/> 

TT_Source" minOccurs="0"/> 
TT_Open_Datetime"/> 
TT_Close_Datetime"/> 
TT_Short_Description"/> 
TT_Long_Description"/> 

Type"/> 

TT_Impact_Assessment"/> 
Start_Datetime"/> 
Detect_Datetime" minOccurs="0"/> 
:Report_Datetime" minOccurs="0"/> 
End_Datetime"/> 
:TT_Last_Update_Time"/> 
Time_Window_Start" minOccurs="0"/> 
Time_Window_End" minOccurs="0"/> 


Additional Data" minOccurs="0"/> 
Related Activity" minOccurs="0"/> 
History"/> 

Affected_Community" minOccurs="0"/> 
Affected_Service" minOccurs="0"/> 
Location"/> 

Network_Node" minOccurs="0"/> 


End_Line_Location_B" minOccurs="0"/> 
Open Engineer" minOccurs="0"/> 
Contact Engineers" minOccurs="0"/> 
:Close Engineer" minOccurs-"0"/» 
Hash" minOccurs="0"/> 

End Line Location A" minOccurs-"0"/» 


Experimental 


Network Link Circuit" minOccurs="0"/> 


2011 


Work Plan Start Datetime" minOccurs="0"/> 
Work Plan End Datetime" minOccurs="0"/> 
Related External Tickets" minOccurs="0"/> 
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<xs:attribute name="lang" type="xs:language"/> 
</xs:complexType> 
</xs:element> 


<a 


== Partner ID Class == 


<xs:element name="Partner_ID" type="nttdm:string_no_underscore"/> 


AE 


== Original ID Class == 


--> 
<xs:element name="Original_ID" type="nttdm:string_no_underscore"/> 


El 


== TT ID Class == 


<xs:element name="TT ID" type="xs:string"/> 


Sl 


== TT Title Class == 


<xs:element name="TT Title" type="xs:string"/> 


«== 


== TT Type Class == 


--» 
«xs:element name-"TT Type" type-"nttdm:eTT Type"/» 


<I> 


== TT Priority Class == 


--> 
<xs:element name="TT_Priority" type="nttdm:eTT_Priority"/> 


Zisiadis, et al. Experimental [Page 34] 


RFC 


6137 NTTDM February 


< lists 


== TT Status Class == 


<xs:element name="TT Status" type="nttdm:eTT_Status"/> 


SS = 


== TT Source Class == 


<xs:element name="TT_Source" type="nttdm:eTT_Source"/> 


Sle 


== TT_Open_Datetime Class m 


--» 
«xs:element name-"TT Open Datetime" type-"xs:dateTime"/» 


sies 


== TT Close Datetime Class == 


<xs:element name="TT_Close_Datetime" type="xs:dateTime"/> 


sies 


== TT Short Description Class == 


--» 
«xs:element name-"TT Short Description" 
type-"nttdm:eTT Short Description"/» 


Slee 


== TT_Long_Description Class m 


--» 
<xs:element name-"TT Long Description" type="xs:string"/> 


2011 
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<= 


== Type Class == 


--» 
<xs:element name="Type" type="nttdm:eType"/> 


SS = 


== TT Impact Assessment Class == 


--> 
<xs:element name="TT_Impact_Assessment" 
type="nttdm:eTT_Impact_Assessment"/> 


Sila 


== Start Datetime Class == 


<xs:element name="Start_Datetime" type="xs:dateTime"/> 


ele 


==  Detect Datetime Class == 


<xs:element name="Detect_Datetime" type="xs:dateTime"/> 


slee 


== Report Datetime Class == 


--» 
<xs:element name-"Report Datetime" type="xs:dateTime"/> 


<= 


== End Datetime Class == 


<xs:element name="End Datetime" type="xs:dateTime"/> 


2011 
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<a 


== TT_Last_Update_Time Class == 


--» 
«xs:element name-"TT Last Update Time" type-"xs:dateTime"/» 


E 


== Time Window Start Class == 


<xs:element name="Time_Window_Start" type="xs:dateTime"/> 


Sle 


== Time Window End Class == 


<xs:element name="Time_Window_End" type="xs:dateTime"/> 


sies 


== Work Plan Start Datetime Class == 


<xs:element name="Work_Plan_Start_Datetime" type="xs:dateTime"/> 


sis 


== Work Plan End Datetime Class == 


<xs:element name="Work_Plan_End_Datetime" type="xs:dateTime"/> 


epe 


== Related External Tickets Class == 


<xs:element name="Related_External_Tickets" 
type="nttdm:eRelated_External_Tickets"/> 
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«lu 


== Additional Data Class == 


<xs:element name="Additional_Data" type="xs:string"/> 


Sila 


== Related Activity Class == 


--» 
<xs:element name-"Related Activity" 
type-"nttdm:eRelated Activity"/» 


AE 


== History Class == 


--» 
<xs:element name-"History" type="xs:string"/> 


les 


== Affected Community Class == 


--» 
<xs:element name-"Affected Community" type="xs:string"/> 


ee 


== Affected Service Class == 


<xs:element name="Affected_Service" type="xs:string"/> 


Se 


== Location Class == 


<xs:element name="Location" type="xs:string"/> 


2011 


Zisiadis, et al. Experimental [Page 38] 


RFC 


6137 NTTDM February 2011 


<a 


== Network Node Class 


<xs:element name="Network_Node" type="nttdm:eNodes"/> 


Silos 


== Network Link Circuit Class 


<xs:element name="Network Link Circuit" 
type-"nttdm:eNetwork Link Circuit"/» 


AE 


== End Line Location A Class 


<xs:element name-"End Line Location A" type="xs:string"/> 


ele 


== End Line Location B Class 


<xs:element name-"End Line Location B" type="xs:string"/> 


Sio 


== Open Engineer Class 


--> 
<xs:element name="Open_Engineer" type="xs:string"/> 


Slee 


== Contact Engineers Class 


--» 


«xs:element name-"Contact Engineers" type-"nttdm:eEngineers"/» 
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<= 


== Close Engineer Class == 


--» 
<xs:element name-"Close Engineer" type="xs:string"/> 


Sica 


== Hash Class == 


<xs:element name="Hash" type="xs:string"/> 


Sle 


== Custom types definition == 


--» 

«xs:simpleType name-"string no underscore"» 
«xs:restriction base="xs:string"> 
«xs:pattern value-"[^ ]*"/» 
</xs:restriction> 

</xs:simpleType> 


<xs:complexType name="eRelated_External_Tickets"> 
<xs:sequence> 
<xs:element name="TTid" type="xs:string" minOccurs="0" 
maxOccurs="unbounded"/> 
</xs:sequence> 
</xs:complexType> 


<xs:complexType name="eRelated_Activity"> 
<xs:sequence> 
<xs:element name="TT" type="xs:string" minOccurs="0" 
maxOccurs="unbounded"/> 
</xs:sequence> 
</xs:complexType> 


<xs:complexType name="eNodes"> 
<xs:sequence> 
<xs:element name="Node" type="xs:string" minOccurs="0" 
maxOccurs="unbounded"/> 
</xs:sequence> 
</xs:complexType> 
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<xs:complexType name-"eNetwork Link Circuit"» 
<xs:sequence> 
<xs:element name-"Link Circuit" type="xs:string" 
minOccurs="0" maxOccurs-"unbounded"/» 
</xs:sequence> 
</xs:complexType> 


<xs:complexType name="eEngineers"> 
<xs:sequence> 
<xs:element name="Engineer" type="xs:string" minOccurs="0" 
maxOccurs="unbounded"/> 
</xs:sequence> 
</xs:complexType> 


<xs:simpleType name="eTT_Type"> 
<xs:restriction base="xs:string"> 
<xs:enumeration value="Operational"/> 
<xs:enumeration value="Informational"/> 
<xs:enumeration value="Administrative"/> 
<xs:enumeration value="Test"/> 
</xs:restriction> 

</xs:simpleType> 


<xs:simpleType name="eType"> 
<xs:restriction base="xs:string"> 
<xs:enumeration value="Scheduled"/> 
<xs:enumeration value="Unscheduled"/> 
</xs:restriction> 

</xs:simpleType> 


«xs:simpleType name="eTT_Priority"> 
<xs:restriction base="xs:string"> 
<xs:enumeration value="Low"/> 
<xs:enumeration value="Medium"/> 
<xs:enumeration value="High"/> 
</xs:restriction> 
</xs:simpleType> 
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<xs:simpleType name="eTT_Short_Description"> 
<xs:restriction base="xs:string"> 


«xS 
«xS 
«xS 
«xS 
«xS 
«xS 
«xS 
«xS 
<xs 
<xs 
<xs 
<xs 
<xs 

</xs 


:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:restriction> 


</xs:simpleType> 


value="Core Line Fault'"/> 
value="Access Line Fault"/> 
value="Degraded Service"/> 
value="Router Hardware Fault"/> 
value="Router Software Fault"/> 
value="Routing Problem"/> 
value="Undefined Problem"/> 
value="Network Congestion"/> 
value="Client Upgrade"/> 
value="IPv6"/> 

value="QoS"/> 

value="VoIP"/> 

value="Other"/> 


<xs:simpleType name="eTT_Impact_Assessment"> 
<xs:restriction base="xs:string"> 


<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
</xs 


:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:restriction> 


</xs:simpleType> 


value="No impact"/> 

value="Reduced redundancy"/> 
value="Minor performance impact"/> 
value="Severe performance impact"/> 
value="No connectivity"/> 

value-"On backup"/> 

value="At risk"/> 

value="Unknown"/> 


<xs:simpleType name="eTT_Status"> 
<xs:restriction base="xs:string"> 


«xs 
«xS 
«xS 
«xS 
«xS 
«xS 
«xS 
«xS 
«xs 

«/xs 


:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:enumeration 
:restriction> 


</xs:simpleType> 
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value="Opened"/> 
value="Updated"/> 
value="Closed"/> 
value="Solved"/> 
value="Opened/Closed"/> 
value="Inactive"/> 
value="Cancelled"/> 
value="Reopened"/> 
value="Superseded"/> 


Experimental [Page 


February 2011 


42] 


RFC 6137 NTTDM February 2011 


<xs:simpleType name="eTT_Source"> 
<xs:restriction base="xs:string"> 
<xs:enumeration value="Users"/> 
<xs:enumeration value="Monitoring"/> 
<xs:enumeration value="Other NOC"/> 
</xs:restriction> 

</xs:simpleType> 

</xs:schema> 


7. Security Considerations 


The NTTDM data model defines a data model and the relevant XML Schema 
for trouble ticket normalization; as such, the NTTDM itself does not 
raise any security concerns. However, some security issues SHOULD be 
considered as network TTs could carry sensitive information (IP 
addresses, contact details, authentication details, commercial 
providers involved, etc.) about flagship institutions (military, 
health centre...). 


The security considerations MAY involve measures during the exchange 
as well as during processing of the information. 


The HASH field is intended to provide an integrity insurance 
attribute within the exchanged tickets; however, it alone does not 
ensure integrity. 


Confidentiality MAY be ensured by encrypting whole tickets or only 
some parts of them. This could permit meaningful tickets to be 
disclosed, while only sensitive information would be protected. 


Peer entity authentication SHOULD be provided in order to establish a 
session with data origin authentication, regardless of the form in 
which the TTs are exchanged -- being delivered either through email, 
web forms, or through a Simple Object Access Protocol (SOAP) service. 
SOAP is considered the better choice; the model itself, though, does 
not specify the communications requirements. 


The underlying communications service MUST provide guarantees to 
properly address integrity, confidentiality, and peer entity 
authentication. The selection of the enforcing mechanisms is not in 
the scope of this document, and the choice is up to the implementers. 


For data processing security, each participating organization MAY use 
its own privacy policy, as part of its own data processing system. 
This approach avoids any interoperability issues and does not pose 
any extra burden for the adoption of the current scheme into the 
operational procedures of the NOCs. Unauthorized and inappropriate 
usage MUST be avoided. 
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8. 


IANA Considerations 


This document uses URNs to describe an XML namespace and Schema 
conforming to a registry mechanism described in [7]. 


Registration for the NTTDM namespace: 
o URI: urn:ietf:params:xml:ns:nttdm-1.0 


o Registrant Contact: See the first author listed in the "Authors’ 
Addresses" section of this document. 


o XML: None. Namespace URIs do not represent an XML specification. 
Registration for the NTTDM XML Schema: 
o URI: urn:ietf:params:xml:schema:nttdm-1.0 


o Registrant Contact: See the first author listed in the "Authors’ 
Addresses" section of this document. 


o XML: See the XML Schema in Section 6 of this document. 
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